Lambda the Ultimate

Ronald Loui, In Praise of Scripting: Real Programming Pragmatism, IEEE Computer, vol. 41, no. 7, July 2008. [Openly accessible draft here]

The July IEEE Computer carries an article arguing for the use of scripting languages as first programming languages, and also arguing for a greater study of what the author calls "language pragmatics" (the original article is behind the IEEE paywall, but you can find a draft that has roughly the same content here). The argument for using scripting languages as educational languages can be summed up by Loui's abstract:

The author recommends that scripting, not Java, be taught first, asserting that students should learn to love their own possibilities before they learn to loathe other people's restrictions.

The bulk of the article is devoted to exploring this basic theme in more depth, and provides an interesting contrast to the arguments in favor of moving away from Java (and scripting languages) advanced in Computer Science Education: Where Are the Software Engineers of Tomorrow? (discussed earlier on LtU here).

Loui spends the latter part of the article arguing that, in addition to syntax and semantics, research on programming language should include a formal study of language pragmatics. According to Loui, a formal study of pragmatics would address questions such as:

• What is the average lifetime of a program written in language X for programmers of type Y, for a program of type Z?
• What is the average time spent authoring versus debugging a program in language X for programmers of type Y, for a program of type Z?
• What is the consumption of short-term memory when programming in language X for programmers of type Y, for a program of type Z?

A command-line, textual, and probably linguistic, interface to the browser.

I am not sure how complex they are planning of making this, nor how it meshes with visions of the future of web browsing, but it's worth keeping an eye on.

I spent some time thinking about site-specific scripting, and had some discussions with students about building a site-specific DSL compiled to Greasemonkey scripts, but alas nothing came of it. It would be interesting to see whether Ubiquity command lines could be integrated into scripts, and how extensible the vocabulary is going to be, and on what level (i.e., site by site, via plugins etc.) Clearly also related to the often discussed topic of "end-user programming".

The proceedings of the 2008 LLVM Developers' Meeting have been posted. The presentations included some overviews of various LLVM subsystems and internals and a few projects targeting the LLVM. Previous meeting's proceedings are also available.

I guess we should note the attempts to smooth over the split amongst implementers that is going down in the JavaScript community with the Oslo Summit and Harmony trying to bring back peace. All programming languages are politics. The attempt to do the right things runs into competing interests and debates over what is the right thing to do. The split in the JavaScript community has been apparent now for a while, with the incrementalists wrapped up in version 3.1 and the more ambitious wrapped up in 4.0. Here's hoping that the wheels don't fall off. From a programming language standpoint, the particulars aren't as interesting as observing how language evolution takes place.

I had received the announcement for the Continuation Fest 2008, but then completely forgot about it. Back in mid-April, some neat stuff was going on in Tokyo:

• Demo of persistent delimited continuations in OCaml for nested web transactions, Oleg Kiselyov, [Slides]. (I wish I had seen that a few years back when I was fooling with the Infernal Device. Just beautiful.)
• How to implement continuation only language in gcc 4.x, Shinji Kono, [Slides].
• Continuing from the past: An approach to building dynamically upgradable applications, Takuo Watanabe and Yuichi Tanaka, [Slides].
• Plus others....

[Edit: fixed url.]

In the past year I have been passionately fighting what Simon Peyton Jones calls "the effects monster", although often it feels like I am fighting windmils instead. No useful programs can be written without effects, but effects turn bad when they are observable from within the program itself. Instead we should strive for encapsulating effects such that they become harmless first class pure values, but more on that in the future. In this first installment in a longer series on the perils of side-effects, we will look at one of the most beautiful examples of observable effects, namely closures and variable capture in imperative languages.

Those of us not at ESSLLI 2008 might want to follow the action using the as usual excellent web site, which contains complete course materials.

Alas, it seems that this year less courses are directly relevant to LtU, but since both logic and linguistics tend to come up around here fairly often I am sure you'll find at least a couple of courses that will whet your appetite.

As a follow up to the previous post, check out how Chung-chieh Shan applied regions to a seemingly unrelated problem. His post begins by explaining how automatic (numerical) partial differentiation can be implemented, and goes on to show how to use regions to avoid mixing-up the variables being differentiated.

Oleg Kiselyov and Chung-chieh Shan. Lightweight Monadic Regions. Haskell'08.

We present Haskell libraries that statically ensure the safe use of resources such as file handles. We statically prevent accessing an already closed handle or forgetting to close it. The libraries can be trivially extended to other resources such as database connections and graphic contexts...

Region annotations are part of an expression's inferred type. Our new Haskell encoding of monadic regions as monad transformers needs no witness terms. It assures timely deallocation even when resources have markedly different lifetimes and the identity of the longest-living resource is determined only dynamically.

For contrast, we also implement a Haskell library for manual resource management, where deallocation is explicit and safety is assured by a form of linear types. We implement the linear typing in Haskell with the help of phantom types and a parameterized monad to statically track the type-state of resources.

I am starting to think we need a department for effect systems and related topics (though we managed without a monads department!)...

You'll probably want to read the code, so go ahead. The code makes it plain which features of the type system are needed to achieve the end result.

Got this in my inbox earlier this week:

Date: Tue, 5 Aug 2008 09:01:12 +0000 (GMT)
From: Jose F. Poveda 
Subject: Re: Problem compiling qsort in mondrian
To: Mondrian Team 
MIME-Version: 1.0

Nigel,
Hi again!! And thanks for your help, it's been
quite useful. I suppose I'm the only person
using Mondrian (hopefully), but the thing is
that I'm implementing quicksort in all languages
of the history. The idea is a historical and
multimedia poster with code incrustated on it,
to include it at the computer science museum of
the city of Malaga. That's why I'm tricking on
mondrian and in many other languages that
probably are useless. And I also worked with F#,
Haskell and as I told you before many many
others.

Regards and thanks again.

Jose F. Poveda
LCC Department
University of Malaga

Scary how time flies. Just eight years ago I joined Microsoft as a young man dreaming of bringing fundamentalist functional programming to the masses. Now I am an old man whose language is inducted to the graveyard of dead programming languages. Apart from this great honor, I believe Mondrian was also briefly mentioned in Guy Steele and Richard Gabriel's fantastic "fifty in fifty" performance, but I was too blown away so I am not sure. Will have to watch the rerun at JAOO extra carefully.